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AMENDMENTS TO THE SPECIFICATION 

Please amend the specification as follows. 

On page 1 of the specification, please replace the paragraph beginning at line 12 with the 
following paragraph: 

This application further expressly incorporates by reference and makes a part hereof the 
following U.S. Patent Application Serial Nos. 10/040,887, 10/040,908 (published on July 10, 2003 
under Publication No. US-2003-0130624-A1), 10/059,929 (published on July 31, 2003 under 
Publication No. US-2003-0141981-A1), the following U.S. Provisional Patent Application Serial 
Nos. 60/377,027, 60/376,625 and 60/376,655, and U.S. Patent No. 5,842,841. This application also 
expressly incorporates by reference and makes a part hereof the following U.S. Patent Applications: 
EIS 5909A, EIS 5909B, EIS 5909C, EIS 5909D, EIS 5909E, EIS 5909F, EIS 5909G, and EIS 
§9Qm Application Serial Nos. 10/749.101, 10/748,762, 10/748,750. 10/748.749, 10/749,099, 
10/748,593, and 10/748,589 , which were all filed concurrently with the present application on 
December 30, 2003. 

On page 4 of the specification, please replace the paragraphs at lines 16 and 17 with the 
following paragraphs: 

FIGURE [[16a]] 16A is a view of an alarm/alert interface screen; 
FIGURE [[16b]] 16B is another view of an alarm/alert interface screen; 

On page 4 of the specification, please replace the paragraphs at lines 27-29 with the following 
paragraphs: 

FIGURE [[25a]] 25A is a view of an allergies and height/weight interface screen; 
FIGURE [[25b]] 25B is a view of a medication history interface screen; 
FIGURE [[25c]] 25C is a view of a lab results interface screen; 
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On page 4 of the specification, please replace the paragraphs at lines 31-34 with the 
following paragraphs: 

FIGURE [[27]] 26A is another view of an interface screen of the medication delivery 
schedule process of FIGURE 26; 

FIGURE [[27a]] 27A is a view of an interface screen of a workflow infusion stop; 
FIGURE [[27b]] 27B is another view of an interface screen of a workflow infusion stop; 

On page 5 of the specification, please replace the paragraph at line 1 with the following 
paragraph: 

FIGURE [[27c]] 27C is a view of an interface screen of a workflow to resume an infusion; 

On page 5 of the specification, please add the following paragraph at line 2: 

FIGURE 27D is another view of an interface screen of a workflow to resume an infusion; 

On page 5 of the specification, please replace the paragraph at line 14 with the following 
paragraph: 

FIGURE [[38a]] 38A is a view of another scan pump channel interface screen; 

On page 5 of the specification, please replace the paragraph at line 16 with the following 
paragraph: 

FIGURE [[39a]] 39A is another view of a comparison interface screen; 

On page 5 of the specification, please replace the paragraph at lines 22-23 with the 
following paragraphs: 

FIGURE [[45a]] 45A is a view of a communication loss interface screen; 
FIGURE [[45b]] 45B is a view of a communication loss interface screen; 
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On page 5 of the specification, please replace the paragraph at line 29 with the following 
paragraph: 

FIGURE [[50a]] 50A is a view of a monitoring parameter entry interface screen; 

On page 6 of the specification, please replace the paragraph beginning at line 29 with the 
following paragraph: 

Turning to FIGURE 3, the patient care system 100 can include a plurality of medical devices 
120. In one embodiment, the medical device is an infusion pump 120. Further, in another 
embodiment the medical device is a controller for an infusion pump. For ease of reference, this 
disclosure will generally identify the medical device of the system as an infusion pump, however, it 
is understood that the overall system 100 may incorporate any one or more of a variety of medical 
devices. Accordingly, as shown in FIGURE 3, a plurality of infusion pumps 120 are connected to a 
hub or interface 107. As explained in detail further herein, the infusion pumps 120 can be of 
conventional design wherein each infusion pump 120 is associated with a patient. However, as will 
be appreciated by those having ordinary skill in the art, the infusion pumps 120 shown in FIGURE 3 
do not have to be associated with the same patient or treatment location even though the infusion 
pumps are connected to the same hub 107. Moreover, each infusion pump 120 can be a single 
channel pump or a multiple channel pump, such as a triple channel pump. Any such chann e l is 
id e ntifi e d with ref e r e nc e numb e r 121. Typically, the pumps transmit messages containing pump 
status information on a periodic basis to the hub 107. A separate hub 107 can be used apart from the 
medical device 120 in order to centralize communications, for cost efficiencies, and/or to allow for 
retrofitting of existing medical devices that do not currently communicate with a central computer 
system 108 so that each such medical device can communicate with a central computer system 108. 

On page 13 of the specification, please replace the paragraph beginning at line 10 with the 
following paragraph: 

In one embodiment, the first central computer 109 can comprise a validated server, such 
as a Compaq DLG-380 with Windows 2003 Server OS, running Active Directory for user and 
device authentication, Certificate Authority for issuance of server and client certificates, SQL 
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Server 2000 for temporary data storage, Internet Information Server (IIS) for application hosting 
(Web Services and Web pages). The second central computer 108a can comprise a non- validated 
Server, such as an external Hospital Information System (HIS) Server connected through a 
dedicated Ethernet TCP/IP connection 103 accessing a data replication Web service exposed by 
the validated server at the other end of the dedicated connection. The second central computer 
108a can alternatively comprise software for performing one or more of the various 
functionalities described in general herein, such as a pharmacy and other systems. Thus, the 
second central computer [[and]] can comprise these types of functions and have an interface with 
other systems, such as an external Hospital Information System (HIS) Server. 

The first central computer (i.e., server 109) includes a database containing a data storage 

package or first database. In an embodiment, the first database can be external or internal to the 
first central computer 109, but preferably is only accessible to users of the application 5412, as 
shown in FIGURE 54, loaded on the first central computer. The data tables within the first 
database are used within the use cases described further herein. Preferably, the data tables 
include tables related to medical devices, digital assistants, hubs, patients, clinician, 
prescriptions, titration, comparison information, alarms, and escalations. Moreover, medical 
device tables can include tables related to pump, pump channel, pump sub-channel. Also, alarm 
tables can include tables related to hub alarms, pump alarms, channel alarms, an alarm history 
log, and the like. 

On page 16 of the specification, please replace the paragraph beginning at line 11 with the 
following paragraph: 

The first central computer subsystem preferably consists of a server 109 with a software 
application loaded and configured for sending and receiving data to and from multiple hubs 107, 
multiple digital assistants 118, and the second central computer sub-system comprising [[sever]] 
server 108a. 
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On page 16 of the specification, please replace the paragraph beginning at line 15 with the 
following paragraph: 

Turning to FIGURE 54, server 109 is preferably a COMPAQ DLG-380 with a MICROSOFT 
WINDOWS 2003 Server operating system 5414. In one embodiment, software components that are 
loaded within the memory of the first central computer 109 include a first central computer or server 
application 5412 within a NET framework 5416, an Active Directory Domain Service 5418 for users 
and device authentication, an SQL Server 5420 (show as a database) for temporary data storage, and 
Internet Information Server [[542]] 5422 (IIS) for application hosting. The NET framework 5416 is 
preferably Microsoft NET framework 1 . 1 or greater wherein the NET framework connects the first 
central computer application 5412 to the operating system, Internet Information Server 5422, SQL 
Database 5420, and Active Directory Domain Service 5418 components. As will be appreciated by 
those having ordinary skill in the art, the Active Directory Domain Service 5418 provides services 
utilized by the Windows Server Operating System 5414 and the first central computer application 
5412 to assist in ensuring that only authentic and authorized hub subsystem, second central computer 
subsystem and users of the personal digital assistant subsystem have access to the first central 
computer and thus the first central computer application 5412. 

On page 18 of the specification, please replace the paragraph beginning at line 6 with the 
following paragraph: 

As shown in FIGURE 54, the incoming messages are routed via the Internet Information 
[[Sever]] Server and the NET framework components to the application 5412 loaded on the first 
central computer (i.e., server 109 of FIGURE 3). The first central computer application 5412 utilizes 
the Active Directory Domain Service 5418 to verify that the second central computer message is 
authentic, processes the contents, and then stores the resulting data in the SQL server database 
component 5420. 

On page 18 of the specification, please replace the paragraph beginning at line 12 with the 
following paragraph: 

The application 541 2 loaded on the first central computer then responds to the second central 
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computer by issuing an HTTP response method that is routed via the NET framework component 
5416 and internet information [[sever]] server component 5422 to the second central computer. This 
response message indicates the success or failure of the data transfer and processing. 

On page 21 of the specification, please replace the paragraph beginning at line 13 with the 
following paragraph: 

Accordingly, the RoutePDA incoming interface is utilized for communication with the web 
browser located in the PDA(s) 118. This interface receives incoming HTTP request messages 
containing data encoded as name-value pairs consistent with the HTTP "GET" and "POST" 
protocols. The incoming messages are routed via the Internet Information [[Sever]] Server and the 
NET Framework component to the application 5412 loaded within the first central computer. The 
application 5412 loaded on the first central computer reroutes the incoming message to the second 
central computer utilizing the NET framework 5416 and the RoutePDA outgoing interface as 
discussed below. 

On page 23 of the specification, please replace the paragraph beginning at line 12 with the 
following paragraph: 

The incoming messages are routed via the Internet Information [[Sever]] Server and the Net 
framework components to the application 5412 loaded within the first central computer application. 
The first central computer application utilizes the Active Directory Domain Service component to 
verify that the hub subsystem message is authentic. The first central computer then processes the 
contents, and stores the resulting data in the SQL Server Database component. Finally, the first 
central computer application issues an HTTP response message to the sending hub device via the 
NET framework and Internet Information [[Sever]] Server components. This response messages 
indicated the success or failure of data transfer and processing. 

On page 27 of the specification, please replace the paragraph beginning at line 10 with the 
following paragraph: 

The infusion system 210, or healthcare system 210, within the [[patent]] patient care system 
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100 provides computerized prescribing and an electronic medical administration record (eMAR), 
among other things. Infusion system 210 puts charting, medication history, inventory tracking, and 
messaging at the clinician's fingertips. Patient care system 100 combines bar-coding and real-time 
technology to assist in ensuring that the right patient gets the right medication and the right dosage, at 
the right time, via the right route. Infusion system 210 provides alerts, alarms, messages, and 
reminders such as, but not limited to, lab value, out of range, and missed dose. As part of the 
verification of the right dosage, the system can also provide verification of the settings of an infusion 
pump. 

On page 38 of the specification, please replace the paragraph beginning at line 17 with the 
following paragraph: 

Any process descriptions or blocks in figures, such as [[FIGS.]] FIGURES 3-11, are to be 
understood as representing modules, segments, or portions of hardware, software, or the like, that can 
include one or more executable instructions for implementing specific logical functions or steps in 
the process, and alternate implementations are included within the scope of the embodiments in 
which functions can be executed out of order from that shown or discussed, including substantially 
concurrently or in reverse order, depending on the functionality involved, as would be understood by 
those having ordinary skill in the art. 

On page 39 of the specification, please replace the paragraph beginning at line 1 with the 
following paragraph: 

The medication management module 302 can coordinate the functions of the other modules 
in the patient care system 100 that are involved in the administration of medical treatment. The 
medication management module 302 generally coordinates with other portions of the patient care 
system 100. The medication management module 302 can include sub-modules for operating and/or 
interfacing with a CPOE, for operating and/or communicating with point-of-care modules, and for 
operating and/or communicating with medical treatment comparison modules. In FIGURE 4, an 
admissions, discharge, and transfer (ADT) interface 310, a billing interface 312, a lab interface 314, 
and a pharmacy interface 316 are shown. The ADT interface 3 10 is used to capture information such 
as the patient's demographics, size, weight, and allergies. In a preferred embodiment, the ADT 
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system utilizes an HL7 type of interface to transfer events that are entered into the hospital's ADT 
system into the second central server 108a. HL7 is a protocol for formatting, transmitting and 
receiving data in a healthcare environment. It provides interoperability between healthcare 
information systems through a messaging standard that enables disparate healthcare applications, 
such as a variety of different third-party applications, to exchange key sets of clinical and 
administrative data. Typically, in the present system 100, the HL7 ADT interface consists of three 
applications: the HL7 ADT server, the HL7 ADT client, and the HL7 ADT viewer. The pharmacy 
interface 316 imports orders from the pharmacy. The pharmacy interface 316 can be an HL7-type of 
interface that interfaces with other systems for entering orders, such as a CPOE. This ability reduces 
the necessity for entering data into the patient care system 100 more than once. The pharmacy 
interface 316 can be configured to communicate with commercially available third-party systems 
such as, but not limited to Cerner, HBOC, Pyxis, Meditech, SMS, Phamous, and the like. A web 
services interface can provide near real-time coordination between Point of Care medication 
management systems supporting oral medication dosing such as McKesson AdminRx, Pyxis VerifS, 
etc. and infusion pump related medication management. Various other interfaces are also known to 
those having ordinary skill in the art, but are not shown in FIGURE 4. 

On page 42 of the specification, please replace the paragraph beginning at line 10 with the 
following paragraph: 

Clinician 116 identifies him/herself by scanning badge 116a, identifies the patient 112 by 
scanning wristband 112a, identifies the medication 124 by scanning medication label 124a, and 
identifies the medical device 332, such as infusion pump 120, by scanning label 120d. Clinician 1 16 
can also identify him/herself by providing a fingerprint and/or password as described above and 
shown in the login screen [[503]] 1903 of FIGURE 19. The medical device 332 can be a medical 
device capable of two-way communication with the medication management module 302. 
Alternatively, the medical device 332 can only be capable of providing information to the medication 
management module 302. The infusion system 210 assists the clinician 1 16 in administering and 
verifying the medical treatment. In an alternate embodiment, the infusion system 210 can include 
downloading of operating parameters to the medical device 332. Clinician 116 can provide a visual 



Preliminary Amendment 

U.S. Application No. 10/749,102 

Attorney Docket No. EIS-5909A (1417G P 858) 

Page 10 

verification to confirm the third copy 322 and/or the MAR matches the labeled medication 124. 
Scanner 338 can be used to enter machine readable information from the third copy 322 to the 
wireless device 330 and the medical device 332. 

On page 46 of the specification, please replace the paragraph beginning at line 16 with the 
following paragraph: 

Infusion order creation 504 includes functional blocks used to create infusion orders: 
Infusion order creation 504 includes functions similar to those described in reference to prescription 
generation 304 (FIGURE 4). Infusion order creation 504 includes, but is not limited to, entering 
information 560, calculations 562, checks 564, and overrides [[568]] 566. Infusion order creation is 
further described below in reference to FIGURE 8. The result of infusion order creation is an 
infusion order 702 (FIGURE 8). Infusion order 702 generally includes an infusion schedule 704 
(FIGURE 8). 

On page 53 of the specification, please replace the paragraph beginning at line 23 with the 
following paragraph: 

FIGURE 8 is a block diagram showing functional components for infusion order creation 504 
of FIGURE 6. Infusion order creation 504 includes functional blocks for creating infusion orders. 
Infusion order creation 504 includes entering information 560, calculations 562, checks 564, and 
overrides [[568]] 566 . Entering information 560 can include functions such as, but not limited to, 
identifying the order type 560a, identifying the medications 560b, identifying the dose 560c, 
identifying the diluent 560d, identifying the flow rate 560e, and identifying the infusion site 560f. 

On page 55 of the specification, please replace the paragraph beginning at line 12 with the 
following paragraph: 

Calculations 562 can include calculations such as, but not limited to, bag quantity 
calculations 562a, translation calculations 562b, duration to volume calculations 562c, and flow rate 
to drip rate calculations 562d. Checks 564 include a variety of checks that an infusion order can be 
subject to. The checks include checks such as, but not limited to, a net concentration check 564a, a 
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flow rate check 564b, an administration time check 564c, a duration check 564d, and an infusion site 
check 564e. If an infusion order fails a check 564, the clinician 116 may be able to override the 
check. Overrides [[568]] 566 can include overrides such as, but not limited to, a net concentration 
override [[568a]] 566a , a flow rate override [[568b]] 566b , an administration time override [[568c]] 
566c , a duration override [[568d]] 566d, and an infusion site override [[568e]] 566e. Overrides 
[[568]] 566 can generate messages 520 for the physician and/or the pharmacy. The infusion system 
210 can distinguish between system-wide and subsystem overrides in determining whether it is 
necessary to generate a message 520. 

On page 55 of the specification, please replace the paragraph beginning at line 24 with the 
following paragraph: 

Overrides can include an indication of whether clinicians have the authority to override a 
tolerance. For example, flow rate override [[568b]] 566b can provide an indication of whether the 
clinician entering the infusion order has the authority to override the system flow rate tolerance 542b. 
This indication can apply to the patient care system 100 or a subsystem. Duration override [[568d]] 
566d can provide an indication of whether the clinician 116 entering the infusion order has the 
authority to override the system duration 542d. This indication can apply to the patient care system 
100 or a subsystem. Overrides 566 also include displaying of reasons for the override [[568f]] 566f. 
Reasons for the overrides [[568f]] 566f can be selected by the clinician 1 16 from drop-down menus. 

On page 60 of the specification, please replace the paragraph beginning at line 17 with the 
following paragraph: 

Modification changes 1002 include identifying a new duration 1002a, identifying a new flow 
rate 1002b, identifying a new infusion site 1002c, identifying a reason for a modification 1002d, 
identifying the volume remaining in the infusion bag 1002e, and stop orders 516. The ordering 
options available during initial infusion order creation 504 are generally available for modifying the 
infusion order. Ordering options available during initial infusion order creation 504 include those 
shown in FIGURE 8. Rechecks 1006 and recheck overrides 1008 are analogous to checks 564 and 
overrides 566 that are described in reference to FIGURE 8. New flow rate to new [[flow]] dri^ rate 
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display 1010 assists the clinician and minimizes the possibility of errors during medication 
administration 512. The modified infusion order can lead to a modified infusion schedule. 

On page 62 of the specification, please replace the paragraph beginning at line 16 with the 
following paragraph: 

Documentation 1012 captures infusion order information in real-time. Documentation 
includes documenting multiple infusions being administered at the same time and infusion 
modifications such as, but not limited to, duration changes [[1002a]] 1012a , flow rate changes 
[[1002b]] 1012b , volume changes 1012c, and infusion site changes [[1002d]] 1012d . 

On page 65 of the specification, please replace the paragraph beginning at line 8 with the 
following paragraph: 

While the present disclosure has focused on the use of infusion pumps 120 within the system 
210, it is understood that other medical devices may be used within the system 210 without departing 
from the scope of the present invention. For example, various types of medical devices include, but 
are not limited to, infusion pumps, ventilators, dialysis machines, etc. An additional type of medical 
device is a micro-electromechanical system (MEMS) component. MEMS is a technology used to 
create small or tiny devices which can be less than a millimeter in size , though they can also be larger 
as well . MEMS el e m e nts devices are typically fabricated from glass wafers or silicon, but the 
technology has grown far beyond its origins [[in]] of the semiconductor industry. Each MEMS 
device is an integrated micro-system on a chip that can incorporate moving mechanical parts in 
addition to optical, fluidic, electrical, chemical and biomedical elements. Th e r e sulting MEMS 
compon e nts Resulting MEMS devices or elements are responsive to many types of input, including 
pressure, vibration, chemical, light, and acceleration. The MEMS components can be a number of 
different elements including various types of pumps, a flow valve, a flow sensor, tubing, a pressure 
sensor or combinations of elements. 



Preliminary Amendment 

U.S. Application No. 10/749,102 

Attorney Docket No. EIS-5909A (1417G P 858) 

Page 13 

On page 65 of the specification, please replace the paragraph beginning at line 22 with the 
following paragraph: 

Accordingly, as explained in further detail below, one use of a MEMS component is as an in- 
line MEMS pump 5314, shown schematically in FIGURE 53. The MEMS pump 5314 is capable of 
pumping fluid contained in the IV bag 5320 through the tube 5312, out through the access device 
5324, and into a patient. The MEMS component has a MEMS local electronics element attached 
thereto, and the MEMS electronics element connects with an external, durable MEMS controller, 
which can communicate with the present system 210 as does the present infusion pump 120 
described herein. In one embodiment of a MEMS pump 5314, the MEMS electronics element 5332 
is embedded therein and can preferably store MEMS parametric operational information. The 
MEMS controller, with its electronics and power source, may be physically or wirelessly connected 
to the MEMS electronics element. In one embodiment, the parametric operational information may 
be loaded from the detachable MEMS controller 5338. Preferably, the pump element 5314 generates 
the fluid flow through a tube 53 12 based on information stored locally within the MEMS electronics 
5332. This information is preferably downloaded from a wired but detachable MEMS controller 
5338. Further, the MEMS components may communicate with the system 210 via wireless 
communication. Additionally, the MEMS controller may provide a transfer of information to and 
from the system 210 to fully automate the control and interrogation of the MEMS components in the 
present system 210 through a wireless or wired communication path. 

On page 72 of the specification, please replace the paragraph beginning at line 25 with the 
following paragraph: 

A patient information menu interface screen 2521, shown in FIGURE 25, is also available on 
the present system. The patient information menu screen 2521 provides a mini patient chart for the 
selected patient. The patient menu screen 2521 also provides the clinician 1 16 the ability to link to 
items relating to the patient, such as: administer medications/infusions, stop infusion, resume 
infusion, titrate infusion, flow rate history, pump status, and remove patient from shift. The patient 
menu screen 2521 also has tabs for: Allergies and Ht/Wt, Medication History, and Lab Results. An 
example of an Allergies & Ht/Wt interface screen 2521a is provided in FIGURE [[25a]] 25A. 
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Typically this screen 2521a is displayed when the mini-chart is first opened. It displays information 
about the patient's drug and general allergies, and the last recorded height and weight of the patient. 
An example of a Medication History interface screen 2521b is provided in FIGURE [[25b]] 25B . 
Typically, this screen 2521b provides the clinician with a medication history of the patient within the 
selected look back period. The look back period may be adjusted by the clinician. Finally, an 
example of the lab results interface screen 2521c is provided in FIGURE [[25c]] 25C. Lab results 
are made available in the system 210 through a lab interface. All available results are shown, and 
displayed in reverse chronological order. 

On page 73 of the specification, please replace the paragraph beginning at line 7 with the 
following paragraph: 

An infusion schedule interface screen 2623 for a patient is shown in FIGURE 26. This 
screen 2623 illustrates an infusion schedule for the selected patient. By clicking one of the identified 
orders, such as order 2625 for Morphine Sulfate on the infusion schedule screen 2623, the system 
210 will link to the medication order interface screen 2627 shown in FIGURE [[26a]] 26A. 
Medication order screen 2627 provides a detail of order 2625 for the specified order (i.e., Morphine 
Sulfate). As part of the detailed order 2625, the therapy parameters 2629 are provided, as well as any 
warnings 2631 and the ability to link to additional information 2633. 

On page 75 of the specification, please replace the paragraph beginning at line 16 with the 
following paragraph: 

Next, the clinician 1 16 can select the pump channel mode as shown in the interface screen 
3881 of FIGURE 38. In the pump channel mode interface screen 3881, the therapy 3882 is shown 
and the clinician 1 16 has the option to designate the therapy 3882 as a primary therapy 3884 or a 
piggyback therapy 3883. Each channel of the pump has the ability to operate a primary therapy in 
addition to a piggyback therapy. After the pump channel mode has been selected, the clinician can 
conduct a pump channel scan. FIGURE [[38a]] 38A illustrates a pump channel scan interface screen 
3885. In the pump scan screen 3885, the clinician 1 16 scans the medical device, such as by scanning 
a bar code corresponding to the pump channel 121 and then clicking on the arrow key 4809. 
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On page 75 of the specification, please replace the paragraph beginning at line 25 with the 
following paragraph: 

After the clinician 116 has: (a) scanned the patient, such as on interface screen 2313 of 
FIGURE 23, (b) scanned the medication, such as on interface screen 3465 of FIGURE 34, and (c) 
scanned the pump channel, such as on interface screen 3885 of FIGURE [[38a]] 38A, the clinician 
1 16 can program the infusion pump and conduct a comparison of the programmed infusion pump 
parameters or settings to the parameters of the pharmacy order. 

On page 78 of the specification, please replace the paragraph beginning at line 18 with the 
following paragraph: 

An example of a resultant comparison interface screen 3987 where the comparison results in 
a match is shown in FIGURE [[39a]] 39A, and identified at block 5226 in FIGURE 52. In this 
instance, if the pharmacy prescription parameters and the programmed pump channel settings match, 
the clinician 1 16 is instructed to start the infusion pump 120. 

On page 79 of the specification, please replace the paragraph beginning at line 1 1 with the 
following paragraph: 

After the infusion pump has initiated a therapy, the clinician 1 16 is able to view on his/her 
digital assistant 118 the status of the pump in a pump status interface screen 4391 as shown in 
FIGURE 43. The pump status display 4391 displays a list of all currently active infusions for a given 
patient. Typically, one of five icons will be displayed in conjunction with an infusion in this screen: 
infusion running indicator 4807, infusion standby indicator [[4809]] 4810 , infusion stopped indicator 
481 1, an unknown icon, and a delay icon. The pump status display [[591]] 4391 does not update in 
real-time while a current screen is being displayed; however, by tapping the refresh button 4819, the 
most current real-time pump status screen will be displayed. 

On page 80 of the specification, please replace the paragraph beginning at line 16 with the 
following paragraph: 

Before administering a medication, the clinician 1 16 may be prompted to enter a monitoring 
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parameter, e.g., a heart rate before administering dioxin, or a pain assessment before administering 
morphine. When a monitoring parameter is associated with a medication, each administration of the 
medication displayed on the digital assistant 1 18 has a link to an interface screen where the clinician 
1 16 may enter a value. An example of such an order having a link 5001 to the entry of a monitoring 
parameter is shown in the order displayed in FIGURE 50. After the monitoring parameter link 5001 
is selected, a monitoring parameter entry interface screen 5003, as shown in FIGURE [[50a]] 50A is 
displayed. There, the clinician 1 16 may enter into the system 210 the requested information. 

On page 81 of the specification, please replace the paragraph beginning at line 1 with the 
following paragraph: 

As circumstances require, a clinician may stop a running infusion before it has finished. This 
may be done either with or without a discontinue order in the system to stop the infusion. Infusions 
that have been stopped may be resumed as circumstances require, such as titrating an order. When 
the discontinued infusion 4813 and running infusion icons 4807 are both displayed on the digital 
assistant 1 1 8, the clinician 1 1 6 is instructed to navigate on the digital assistant 1 1 8 to display a list of 
all running infusions for the patient. An example of such a discontinue infusion interface screen 
2727a is provided in FIGURE [[27a]] 27A. In FIGURE [[27a]] 27A the discontinued infusion order 
will be highlighted and indicated as being a discontinued infusion order. The clinician 1 16 will then 
scan the bar code on the solution container for the discontinued infusion, and then scan the patient's 
ID. Next, interface screen 2727b is provided on the clinician's digital assistant 118 as shown in 
FIGURE [[2727b]] 27B. In interface screen 2727b the clinician can enter the time the infusion has 
been stopped, as well as the reason for stopping the infusion. The clinician 1 16 can then physically 
stop the infusion pump 120 by depressing the stop button on the infusion pump 120. 

On page 81 of the specification, please replace the paragraph beginning at line 15 with the 
following paragraph: 

A resume infusion interface screen 2727c is provided in FIGURE [[27c]] 27C. Infusions that 
are recorded as stopped, without an order to discontinue, may be resumed. To resume an infusion the 
clinician 1 16 must initially navigate to the appropriate interface screen on the digital assistant 118. 
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By tapping on the stopped infusion icon 481 1 in the patient menu, a list of all infusions currently 
stopped for the patient will be displayed as shown in interface screen 2727c of FIGURE [[27c]] 27C. 
A prompt is provided for the clinician to select the infusion to be resumed. The clinician 116 then 
scans the bar code on the solution container for the infusion to be resumed. The system 210 
compares the scanned ID to those for the infusions currently stopped for the patient. After the system 
210 compares the ID with those that are currently stopped for the patient, the digital assistant 118 
prompts the clinician 1 16 to scan the patient's ID. The system 210 then confirms that the scanned ID 
matches the patient's ID, and the system 210 will display on the digital assistant 1 18 the description 
of the scanned infusion and prompt the clinician 1 16 to select a facility-defined reason for resuming 
the infusion, as shown in interface 2727d of FIGURE [[27d]] 27D. Once the reason is selected, the 
clinician 1 16 can restart the infusion at the pump 120 and then tap the arrow 4809 to continue. The 
system 210 records the infusion as having been resumed. 

On page 81 of the specification, please replace the paragraph beginning at line 31 with the 
following paragraph: 

As shown in the various screen shots/interfaces for the digital assistant 1 18, a variety of icons 
are utilized to assist the clinician 1 16. Many of these icons are shown in FIGURE 48. The patient 
list button 4801 is a key that, when tapped, allows the clinician 1 16 to navigate directly to the patient 
list screen, such as the patient list screen 2313 shown in FIGURE 23. The back button 4803 is a key 
that, when tapped, returns the screen on the digital assistant 118 to the previous screen. The OK 
button 4805 is tapped to acknowledge data shown on the digital device 118. When the OK button 
4805 is tapped the next screen is usually displayed. The infusion running indicator button 4807 
indicates that a programmed infusion is now running for the selected pump 120 and channel. The 
infusion standby indicator [[4809]] 4810 indicates that a programmed infusion has been put on 
standby for the selected patient, pump 120 and channel. The infusion stopped indicator 4811 
indicates that the programmed infusion has been stopped for the selected patient, pump 120 and 
channel. The infusion discontinue order indicator 4813 indicates that a pharmacy-entered order will 
discontinue an infusion for the selected patient, pump 120 and channel The physician's notes 
indicator 4815 indicates the presence of physician's notes for the selected patient, pump 120 and 
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channel. The clinician 1 16 can tap the notes indicator 4815 to view the notes. The compare button 
4817 is provided in various screens, and when tapped has the system 210 perform a comparison of 
the scanned item with the pharmacy-entered order, as well as additional comparisons. The refresh 
button 4819 is tapped to update and show the latest data on the screen. The exit button 4821 allows 
the clinician to exit the current screen, and return to the previously displayed screen. The enter 
button 4809 is also the OK button and is tapped to acknowledge and enter either data selected from 
choices within a drop-down list, or data manually entered in a field. The comparison match indicator 
4823 indicates that programmed pump settings match pharmacy-entered order information. The 
comparison mismatch indicator 4825 indicates that programmed pump settings do not match 
pharmacy-entered order information. The cannot compare indicator 4827 indicates that the system 
cannot compare the programmed pump settings to the pharmacy-entered order information. The 
pump alarm/alert indicator 4872 indicates that an alarm or alert condition is occurring. When the 
alarm/alert indicator 4872 is tapped, an expanded pump alarm and alert screen is displayed. On the 
alarm and alert screen, a red alarm/alert icon 4872 indicates an alarm condition, and a yellow 
alarm/alert icon 4872 indicates an alert condition. The alarm/alert silence button [[3074]] 4874 is 
tapped to temporarily silence the audible alert on the digital device 118. The loss of communication 
indicator 4833 indicates that the pump 120 and/or the hub 107 is not properly communicating with 
the system 210. A message accompanying this indication describes the steps to take to resolve the 
problem. The wireless module low battery alert indicator 4835 indicates that the hub 107 is presently 
running on a backup battery that has less than 30 minutes of battery power remaining. 

On page 85 of the specification, please replace the paragraph beginning at line 1 1 with the 
following paragraph: 

As explained above, one type of notification is an alarm/alert notification. In the present 
system, notifications may be escalated. A specific alarm/alert escalation process is shown in 
FIGURE 15. Typically, a notification process is provided to transmit notifications to any number of 
clinicians 116. The identified alarm/alert escalation process 1500 of FIGURE 15 provides for 
notifying a series of clinicians via a clinician device 118 when an alarm or alert is active on a medical 
device such as an infusion pump 1 20. In a preferred embodiment, the clinician ' s device is a personal 
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digital assistant ("PDA") 118, such as shown in [[FIGS.]] FIGURES 1 and 3, typically having a 
display 118a and an audible tone or sound generator 118c. For illustrative purposes only, the 
clinician's device will hereinafter be identified in this detailed description as a digital assistant 118. 
Further, the alarm/alert escalation process 1500 provides an escalation process when the clinician 
fails to respond to the alarm/alert notification on the digital assistant 118. When an escalation 
process is started, a notification is provided to another or second clinician's digital assistant 1 18 as 
specified in the escalation procedure. While the alarm/alert notification is sent to the digital 
assistants 1 18, it is understood that typically the pump alarms and alerts can only be resolved at the 
pump. As explained herein, silencing of the alarm or alert at the digital assistant 118 , such as in 
block 1580 of FIGURE 15, may or may not affect the pump. 

On page 87 of the specification, please replace the paragraph beginning at line 7 with the 
following paragraph: 

The signal is received by the clinician's digital assistant 118, and subsequently displayed at 
block 1530 in FIGURE 15. This block provides for indicating the alarm or alert condition on the 
clinician's digital assistant 118. The indication on the clinician's digital assistant may be visual, 
audible, or both visual and audible. Further, the visual indication may include one or more of text, 
icons, symbols, etc. Similarly, as explained above, the audible indication may include a variety of 
audible tones at a variety of decibel levels. The visual and audible indicators are configurable by the 
hospital. FIGURE [[16a]] 16A discloses an exemplar screen shot of an alarm/alert interface list 
screen 1662a on the clinician's digital assistant 1 18. The alarm/alert list interface 1662a contains a 
list of patients that are currently associated to active channel alarm/alerts. As shown in FIGURE 
[[16a]] 16 A , this clinician's digital assistant 118 currently has three active alarm/alert indications. 
There is an alarm condition for patient one 1664, an alarm condition for patient two 1666, and an 
alert condition for patient three 1668. Each patient name and corresponding alarm/alert icon is a 
hyperlink to the appropriate pump alarm details interface screen, as shown in FIGURE 17. In one 
embodiment, the list of patients is filtered to only include the patients that are currently associated to 
the clinician 1 16 logged into the digital assistant 1 18 displaying this interface screen. This clinician- 
to-patient association can be as a primary clinician or as a temporary coverage clinician. A secondary 
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clinician can also be accessed through the escalation process. The alarm/alert list interface 1662 is 
typically accessed by clicking on an alarm/alert icon 4872 displayed on the clinician's 116 digital 
assistant 118 during normal clinician workflow. 

On page 87 of the specification, please replace the paragraph beginning at line 27 with the 
following paragraph: 

As explained above, when the alarm or alert condition is indicated on the clinician's digital 
assistant at block 1530, this indication may be provided visually, audibly or both. When an audible 
indication is provided at the clinician's digital assistant 118, the alarm icon 4872 appears on the 
display 1 18a of the clinician's digital assistant 118. If an audible indication is provided, the clinician 
may have the ability to mute the audible indication even though the clinician has not responded to the 
alarm or alert condition. If the clinician does silence the alarm, the server 109 will initiate a silence 
timer. The visual indication will remain even though the audible indication has been muted. As 
shown in FIGURE [[16a]] 16 A , if an alarm/alert would be providing an audible indication at the 
clinician's digital assistant 1 18 but for the muting by the clinician, a muted alarm/alert icon 4874 is 
provided. Further, upon escalation of the alarm/alert condition, if the clinician does not respond to 
the alarm within the timer limit, the muting of the audible indication may be disengaged. An 
alternate embodiment of the audible indication may be a vibration alert. 

On page 88 of the specification, please replace the paragraph beginning at line 6 with the 
following paragraph: 

Further, it is understood that multiple alarm/alert conditions may occur simultaneously or in 
overlapping periods. Accordingly, simultaneous or overlapping signals containing data relating to 
the specific alarm or alert condition are generated and sent at block 1510 from the medical device 
120, to the server 109. The alarm/alert signals may originate from the same or different medical 
devices 120. Further, the alarm/alert signals may relate to the same or different patients. Each of the 
alarm/alert signals, however, [[are]] is individually routed in the alarm/alert escalation process 1500 
as herein described for an individual alarm/alert condition. As shown in FIGURE [[16a]] 16A, a 
specific clinician may have numerous alarm/alert indications on his/her digital assistant 118. 
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Another example of an alarm/alert screen is shown on interface screen 1662b of FIGURE [[16b]] 
16B . As is typical in the present system, the line referenced as 1676 in interface screen 1662b of 
FIGURE [[16b]] 16B indicates the end of a list, and specifically the alarm/alert indication list for a 
specific clinician in this interface. 

On page 88 of the specification, please replace the paragraph beginning at line 18 with the 
following paragraph: 

FIGURE 17 illustrates a detailed patient alarm/alert interface 1765 after the clinician has 
selected to view one of the alarm/alert indications for the patient hyperlink on the clinician's digital 
assistant 118 from the interface list 1662a of FIGURE [[16a]] 16A . Here, the clinician has selected 
the alarm indication for patient one 1664. The alarm/alert detail screen 1765 provides the clinician 
with a message detailing the reason for the alarm/alert. The clinician can click on the refresh button 
4819 to update the current information displayed on the screen 1765. As shown on interface 1867 of 
FIGURE 18, multiple alarms or alerts 1878, 1882 may exist for the same patient. This alarm/alert 
interface 1867 provides a list of all active pump alarm/alerts that are currently associated to a given 
patient. These active pump alarm/alerts can be from multiple channels 121 and/or pumps 120, and 
even spread across multiple hubs 107. This interface screen 1867 is accessed by specifying a given 
patient on the pump alarm list screen 1662. 

On page 89 of the specification, please replace the paragraph beginning at line 1 1 with the 
following paragraph: 

When an alarm is escalated, the server 109 conducts another precondition check at block 
[[1555]] 1550 . This precondition check [[1555]] 1550 may include: associating the patient with a 
secondary clinician (this association may be conducted at the central system servicing unit 108a); 
and, associating the second clinician with that clinician's digital assistant 118, also referred to as the 
second clinician's device or second clinician's digital assistant 118. The server 109 uses the 
information gained in its precondition check at block [[1555]] 1550 to establish a relationship 
between the medical device 120, the patient, the secondary clinician and the second clinician's digital 
assistant 118. 
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On page 89 of the specification, please replace the paragraph beginning at line 19 with the 
following paragraph: 

Following the second precondition check at block [[1555]] 1550 , the server 109 may also 
determine if the second clinician's digital assistant 118 is active. If the second clinician's digital 
assistant 1 18 is active, then the server 109 generates an escalated signal representative of the alarm or 
alert condition that exists. The escalated signal similarly includes data such as the patient's name, 
patient's location, room identification, bed identification, alarm or alert type, condition description, 
time, date, clinician identification and/or prescription. In the preferred embodiment, the escalated 
signal is transmitted from the server 109 to the wireless access point 1 14. The wireless access point 
114 then transmits the escalated signal relating to the alarm or alert condition via a wireless 
communication transmission to the second clinician's digital assistant 118 at block 1555. 

On page 90 of the specification, please replace the paragraph beginning at line 18 with the 
following paragraph: 

Referring back to block 1520, if the server 109 determines that the primary clinician's digital 
assistant 118 is not active, and if at block 1545 the server 109 determines that the alarm/alert 
condition still exists, the server 109 will proceed to block 1550 as discussed above to determine the 
appropriate secondary or charge clinician to send the alarm/alert signal. Additionally, it is 
understood that block 1520 may occur at any at any time during the alarm/alert escalation process 
1500. One reason for a clinician's digital assistant 1 18 being inactive could be a loss of a signal from 
the server 109. As shown in the communication loss interface screen 4501 of FIGURES [[45a]] 45A 
and [[45b]] 45B, when the signal is lost the digital assistant 1 18 will provide the clinician 1 16 with a 
screen 450 1 , and/or an audible/vibratory indication, indicating a lost signal. The communication loss 
screen 4501 also informs the clinician 1 16 as to which patients the signal has been lost. At screen 
4501 the system 210 also provides the clinician 116 with trouble shooting tips to regain a signal. 
When a hub 107 or digital assistant 118 is outside of the wireless range, pump alarms and alerts 
cannot be received at the digital assistant 1 18. 
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On page 90 of the specification, please replace the paragraph beginning at line 32 with the 
following paragraph: 

Other reasons for the digital assistant 1 1 8 being inactive could be the loss of battery power at 
the digital assistant 1 1 8, a loss of battery power at the wireless hub 107, or the digital assistant losing 
a signal with the access point 1 14. The system 210 does provide the clinician 116 with a low battery 
screen. As shown in interface screen 4603 of FIGURE 46, one type of low battery screen is a screen 
to alert the clinician that a low battery situation exists on a wireless hub 107 connected to a patient's 
infusion pump. When a low battery screen is provided, the screen contains a list of patients for 
which infusions are associated with that specific hub 107. The list of patients is generally filtered to 
include only the patients that are currently associated to the clinician logged into the digital assistant 
118 displaying the screen 4603, and also all patients that share the same infusion pump 120/hub 107 
with the logged-in clinician. This clinician-to-patient association can be as a first clinician or as a 
secondary clinician through the escalation process. It is understood that other reasons for the 
clinician's digital assistant 118 being inactive are possible. Nevertheless, if at any time the 
clinician's digital assistant 118 becomes inactive, the process 1500 may proceed to block [[3100]] 
1550 such that the signal may be sent to a secondary clinician and/or to the charge clinician. Further, 
as explained above with respect to a time-out feature and other features of this disclosure, if a 
communication signal is lost from either the server 109 or the medical device 120, a signal lost 
message may be provided on the digital assistant 1 1 8 as shown in FIGURES [[45a]] 45A and [[45b]] 
45B . 

On page 91 of the specification, please replace the paragraph beginning at line 25 with the 
following paragraph: 

The server 109 records all alarm/alert conditions as an event at block 1585. Recording the 
event may include: recording information on the alarm/alert condition; recording the clinician who 
responded to the alarm/alert condition; recording the initial time of the alarm/alert condition (see 
block 1505); and, recording the time when the alarm/alert condition was rectified. Additionally, at 
block 1590, the server 109 will reset the timer and update [[an]] a medical device alarm list. The 
alarm/alert condition may also be recorded in the pump's event history. 



Preliminary Amendment 

U.S. Application No. 10/749,102 

Attorney Docket No. EIS-5909A (1417G P 858) 

Page 24 

On page 109 of the specification, please replace the paragraph beginning at line 13 with the 
following paragraph: 

If the channel is not running, the first central server 109 causes the digital assistant 1 18 to 
display a "continue overwrite" warning message indicating that a different patient 1 12 is associated 
with the scanned channel, but the channel is not currently running at block 5916. Preferably, the 
warning message indicates that continuing will overwrite existing data (e.g., remove the association 
with the other patient 112). The warning message may also include data indicative of the patient 112 
that is associated with the scanned channel (e.g., patient's name), the primary medication 124, and/or 
the piggyback medication 124. Preferably, the user is given the option to cancel, rescan, or continue. 
If the user chooses to cancel the operation, the first central server 109 sends a cancel code to the 
second central server 108a via the cancellation URL at block 5908. If the user chooses to rescan, the 
first central server 109 causes the digital assistant 118 to display the screen prompting the user to 
scan a machine-readable identifier associated with the channel at block 5902. If the user chooses to 
continue, the first central server 109 causes the digital assistant 1 18 to display a message indicting 
indicating that it is okay to use the selected channel at block 5918. When the user presses "continue" 
the first central server 109 returns control to the current action (e.g., administer, channel change, etc.) 
without issuing additional displays to the digital assistant 118. 

On page 109 of the specification, please replace the paragraph beginning at line 29 with the 
following paragraph: 

If a valid patient identifier is present in the database, and the two patient identifiers do match 
(i.e., the channel is assigned to this patient 1 12) at block 5920, the first central server 109 checks the 
database to see if the channel is empty (e.g., no primary or piggyback infusion associated with this 
channel) at block 5922. If the channel is empty, the first central server 109 causes the digital 
assistant 1 18 to display the message indicting indicating that it is okay to use the selected channel at 
block 5918. If the channel is not empty, the first central server 109 checks the database to see if the 
channel is running (in either primary and/or piggyback mode) at block 5924. 
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On page 1 10 of the specification, please replace the paragraph beginning at line 13 with the 
following paragraph: 

If the channel is not running, the first central server 109 causes the digital assistant 118 to 
display a "continue" message indicating that this patient 1 12 is associated with the scanned channel, 
but the channel is not currently running at block 5928. The message may also include data indicative 
of the patient 112 (e.g., patient's name), the primary medication 124, and/or the piggyback 
medication 124. Preferably, the user is given the option to cancel, rescan, or continue. If the user 
chooses to cancel the operation, the first central server 109 sends a cancel code to the second central 
server 108a via the cancellation URL at block 5908. If the user chooses to rescan, the first central 
server 109 causes the digital assistant 118 to display the screen prompting the user to scan a 
machine-readable identifier associated with the channel at block 5902. If the user chooses to 
continue, the first central server 109 causes the digital assistant 1 18 to display a message indicting 
indicating that it is okay to use the selected channel at block 5918. When the user presses continue 
again, the first central server 109 returns control to the current action (e.g., channel change) without 
issuing additional displays to the digital assistant 118. 

On page 1 16 of the specification, please replace the paragraph beginning at line 1 with the 
following paragraph: 

When the user selects the "resume infusion" action [[form]] from the list of actions, 
information identifying the action selected is sent to the second central server 108a. In response, the 
second central server 108a causes the digital assistant 1 18 to display a screen prompting the user to 
scan a machine-readable identifier associated with the medication 124 to be resumed at block 6106. 
An example of a digital assistant display 118a prompting the user to scan a machine-readable 
identifier associated with the medication 124 is illustrated in FIGURE 34. The user may use the 
scanner of the digital assistant 1 18 to scan the medication label 124a on a bag of medication 124 
(e.g., a barcode on an infusion bag). Alternatively, the user may manually enter the medication 
identifier into the digital assistant 118. 
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On page 1 18 of the specification, please replace the paragraph beginning at line 23 with the 
following paragraph: 

If the infusion is resumed at block 6134, the first central server 109 returns a success code to 
the second central server 108a via the completion URL at block 6144. The first central server 109 
maintains the association between the patient identifier, the medication identifier, and the channel 
identifier for the selected infusion . The second central server 108a only updates the status of the 
infusion to "running" upon receiving a success code from the first central server 109. Any other 
result (e.g., cancel code or failure code) causes the second central server 108a to keep the infusion in 
its previous state. Preferably, if the user wants to resume both a primary infusion and a piggyback 
infusion running on a channel, the user may execute the "resume infusion" action twice, once for 
each infusion. The Resume process may be utilized t document that the infusion was restarted for 
purposes of the MAR. 

On page 1 19 of the specification, please replace the paragraph beginning at line 27 with the 
following paragraph: 

When the user selects the "remove pump" action [[form]] from the list of actions, 
information identifying the action selected is sent to the second central server 108a. In response, the 
second central server 108a causes the digital assistant 1 18 to display a screen prompting the user to 
scan a machine-readable identifier associated with the medication 124 to be affected by this "remove 
pump" action at block 6206. An example of a digital assistant display 1 18a prompting the user to 
scan a machine-readable identifier associated with the medication 124 is illustrated in FIGURE 34. 
The user may use the scanner of the digital assistant 1 18 to scan the medication label 124a on a bag 
of medication 124 (e.g., a barcode on an infusion bag). Alternatively, the user may manually enter 
the medication identifier into the digital assistant 1 18. 

On page 124 of the specification, please replace the paragraph beginning at line 10 with the 
following paragraph: 

The digital assistant 1 18 uses the first central server's digital certificate to authenticate the 
first central server 109 at block 6410. In addition, at block 6412 the digital assistant 118 uses the 
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first central server's digital certificate to retrieve an embedded uniform resource locator (URL) 
associated with the first central server 109. The digital assistant 118 can now request data and 
services [[form]] from the retrieved URL knowing it is talking to the real first central server 109. 

On page 126 of the specification, please replace the paragraph beginning at line 30 with the 
following paragraph: 

The medical device 120 uses the first central server's digital certificate to authenticate the 
first central server 109 at block 6714. In addition, at block 6716 the medical device 120 uses the first 
central server's digital certificate to retrieve an embedded uniform resource locator (URL) associated 
with the first central server 109. The medical device 120 can now request data and services [[form]] 
from the retrieved URL knowing it is talking to the real first central server 109. 



